Security mechanisms intended to protect data stored in an information repository can sometimes hamper legitimate attempts to access data stored in the repository. A secured database or knowledgebase, for example, may be protected by a security gateway, firewall, or other access-restricting mechanism that constrains access to: only those queries that are submitted by an authorized user or client application; only stored data that is authorized to be accessed by a particular user; or only those queries that satisfy an other security-related condition. Furthermore, such an access-restricting mechanism may for similar reasons bar a legitimate attempt to revise data stored in the repository or to store new data in the repository.
In a typical computing environment, a user communicates with an information repository through an intermediate software module known as a driver. In the most general case, an application that manages an information repository will comprise application-specific drivers that handle each user's data-access requests. In a relational-database platform, for example, each user might query information in the database by means of a client-interface module that implements the query by constructing and transmitting an SQL (Structured Query Language) query to an instance of the relational database manager's driver. The driver would then translate the query language into specific commands that instruct the database manager how to perform the query.
In order to efficiently manage a computing environment, such drivers are generally standardized, such that a query or a write request submitted by a user through a repository driver always delivers a predictable set of instructions to the information repository. Standardization is also highly desirable because it simplifies maintenance and configuration tasks, allowing the repository/driver combination to appear to a user to be a black box that responds in a known, deterministic way to a certain set of instructions, regardless of the repository's underlying architecture or platform.
This simple driver-interface architecture works well in an environment in which a user is allowed essentially unrestricted access to contents of an information repository. But when a security mechanism is interposed between the repository and its users, the security mechanism may interpret the driver's generated instructions as posing a security risk and thus block the instructions from reaching the repository.
In some cases, it may be possible to customize each user's drivers to produce instructions that may be allowed by a security mechanism to reach the repository. Such a customized driver might, for example, provide self-authenticating instructions that tell the security mechanism to allow a query to reach the protected repository. But this approach may be cumbersome to the point of being unworkable in a real-world computing environment. In most cases, users do not have access to driver source code and thus cannot alter the operation or functionality of a standardized driver.
Furthermore, tailoring each user's drivers to interoperate with user-specific combinations of security mechanisms, client applications, and information repositories would eliminate benefits of driver standardization. In many cases, the existence of such customized drivers would create support issues that greatly complicate routine tasks like policy upgrades, platform configuration, application patching, and virtual-machine provisioning. Worse, the customized drivers might have to each be manually rewritten every time a corresponding database application or security gateway undergoes a major upgrade, or a security policy is modified.
There is no solution in the prior art that allows a user of a standard client application to seamlessly and transparently overcome such barriers to database access through a security mechanism.